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Abstract 

The  open  system  approach  is  both  a  technical  approach  to  systems  engineering  and  a 
preferred  business  strategy  that  is  becoming  widely  applied  by  commercial  manufacturers  of  large 
complex  systems.  It  has  the  attention  of  DoD  management  who  have  mandated  its  use  by  DoD 
weapon  systems  developers.  Why?  Because  without  such  a  change  in  system  development 
practice,  DoD  risks  being  unable  to  meet  the  technology  needs  of  the  warfighter  in  the  year  2000 
and  beyond  to  maintain  continued  superior  combat  capability  affordably!  Open  systems  designs 
in  both  new  and  legacy  weapon  systems  provide  an  opportunity  towards  this  end;  however,  to 
achieve  good  open  systems  designs  first  demands  that  a  disciplined  systems  engineering 
approach  be  taken  to  defining  the  appropriate  elements  in  the  system  to  be  opened.  This  paper 
discusses  the  need  for  a  rigorous  systems  engineering  process  which  incorporates  open  systems 
concepts  and  principles  —  where  resulting  system  designs  more  readily  accommodate  changing 
technology  to  achieve  cost,  schedule,  and  performance  benefits  by  promoting  multiple  sources  of 
supply  and  technology  insertion. 


1.  Introduction 

As  both  a  technical  approach  to  systems  engineering  and  a  preferred  business  strategy  for 
Department  of  Defense  (DoD)  weapons  systems  acquisitions,  the  open  system  approach  is 
becoming  increasingly  attractive  to  DoD  acquisition  managers  and  systems  developers.  The  open 
systems  approach  is  a  major  change  in  weapons  system  development  practice  applicable  to  both 
new  systems  design  and  legacy  system  upgrade.  As  a  key  acquisition  reform  initiative,  this 
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approach  perhaps  represents  the  only  viable  way  for  DoD  to  maintain  continued  superior 
combat  capability  affordably. 

Today,  legacy  weapons  systems  continue  to  be  developed  with  their  own,  often  unique 
and  frequently  closed,  infrastructures,  making  upgrading  or  modifying  them  over  their  expected 
lifetimes  (20  to  40  years)  both  problematic  and  expensive.  Also,  reduced  procurement  budgets 
and  increased  dominance  of  commercial  technology  cause  acquisition  managers  to  increasingly 
rely  on  commercial  markets  for  affordable  product  development  and  support.  So,  as  DoD’s  role 
shifts  from  being  a  technology  producer  to  being  a  technology  consumer,  it  relies  more  on 
commercial  products  whose  design  is  not  controlled  by  DoD  and  whose  lifetimes  are  much 
shorter  and  more  volatile  than  the  weapons  systems  they  support  (e.g.,  years  vs.  decades).  As  a 
result,  acquisition  managers  risk  relying  on  unique  products  provided  by  a  single  supplier  at  high 
non-competitive  prices  and  with  little  opportunity  for  technology  insertion  by  other  suppliers. 


2.  The  Need  for  an  Open  Systems  Design  Approach 


An  open  systems  design  approach  can  allow  a  weapon  system  program  office  to  achieve 
and  maintain  combat  superiority  in  today’s  challenging  acquisition  environment.  This  approach 
focuses  the  design  process  on  lowering  the  entire  life-cycle  costs  (LCC)  of  weapon  systems  in 
contrast  to  current  practice  in  which  a  disproportionate  focus  is  placed  on  the  short-term  goal  of 
having  the  lowest  development  costs.  Figure  1  illustrates  that  72  percent  of  LCC  are  incurred 
post-IOC  during  the  service  lifetime  [1].  The  ability  of  the  open  systems  design  approach  to 
improve  life-cycle  supportability  is  becoming  an  even  more  important  issue  as  DoD  limits  the 
number  of  new  weapon  systems  procurements  and  extends  the  life  of  the  systems  currently 
fielded. 


Figure  1.  Life  Cycle  Costs 


It  seems  clear  that  DoD  managers  should  concentrate  on  doing  things  in  systems 
engineering  and  development  that  will  decrease  costs  during  production  and  especially  during  the 
operations  and  support  (O&S)  phase.  An  open  systems  approach,  basing  the  weapon  system’s 
design  on  open,  commercially  supported  interface  standards  with  the  prospects  of  a  large 


supplier  and  customer  base,  focuses  the  systems  engineering  process  on  developing  system 
designs  which  consider  life-cycle  support  requirements  up  front  and  that  support  system 
evolution  throughout  the  system’s  life. 

An  open  systems  approach  also  mitigates  the  increased  risks  of  obsolescence  due  to 
shortened  technology  cycle  time.  Obsolescence  risks  are  significant  because  technology  cycle 
time,  sometimes  on  the  order  of  months,  far  outpace  weapon  system  development  cycle  time, 
typically  8  to  15  years.  By  the  time  a  system  is  fielded,  supporting  technologies  are  often 
outdated  —  the  US.  military  cannot  afford  to  be  3  or  4  technological  generations  behind  what  is 
available  to  the  commercial  market.  Open  systems  designs,  using  commercially-supported 
interface  standards  permitting  upgrade  at  a  relatively  low  cost,  specifically  address  issues  of 
affordability  and  supportability  associated  with  long  lived  system  by  facilitating  evolutionary 
upgrade  with  new  technology.  Generally,  this  results  in  superior  combat  capability  over  the  total 
system  life-cycle,  usually  at  a  lower  cost  to  the  government. 

Another  reason  that  open  systems  have  become  so  attractive  is  that  DoD  is  no  longer  the 
dominant  force  in  the  market  place  and  DoD’s  procurement  budget  has  been  drastically  reduced. 
DoD  no  longer  has  the  luxury  of  technology  dominance,  funded  by  seemingly  unlimited  budgets. 
In  prior  decades,  DoD  requirements  drove  development  of  new  products  and  new  technology.  In 
the  today’s  environment  the  opposite  is  true;  commercial  demand  drives  product  and  technology 
development.  However,  DoD  can  now  take  advantage  of  commercial  innovation,  research  and 
development  to  drive  down  its  cost  of  developing,  acquiring  and  maintaining  weapon  systems, 
leveraging  the  commercial  investment  to  make  the  most  of  available  and  shrinking  defense  funds. 
An  open  systems  approach,  using  open  interfaces  supported  by  commercial  and  non- 
developmental  components,  can  substantially  facilitate  this  leveraging. 

The  bottom-line  issue  is  not  only  cost:  the  lives  of  our  servicemen  may  depend  on 
shortened  technology  insertion  cycle  times.  In  a  global  market,  everyone,  including  our  potential 
adversaries,  will  gain  increasing  access  to  the  same  commercial  technology  base.  The  military 
advantage  goes  to  the  nation  that  has  the  best  cycle  time  to  capture  the  very  best  commercially 
available  technologies,  incorporate  them  in  weapon  systems,  and  get  them  fielded  first. 
Moreover,  since  coalition  operations  with  our  allies  place  a  high  premium  on  interoperability,  it 
is  essential  that  our  systems  be  compatible  and  capable  of  being  sustained  through  a  common 
logistics  support  structure.  Open  systems  specifications  and  standards  promote  standard 
interfaces  and  interoperability  with  our  friends  and  allies. 

Each  of  these  many  issues  will  continue  to  substantively  challenge  past  DoD  acquisition 
practices  throughout  the  foreseeable  future.  As  a  result,  DoD  finds  itself  with  few  alternatives 
but  to  drastically  alter  the  way  it  develops,  produces  and  supports  its  weapon  systems.  It  is 
neither  economically  nor  technologically  feasible  to  continue  traditional  closed  design  approaches. 
DoD  is  increasingly  compelled  to  move  towards  a  more  open  weapon  systems  design  alternative. 


3.  Open  Systems  Design  Concepts 


Simply  put,  the  concept  of  open  systems  is  a  common  sense  approach  that  has 
substantial  promise  as  an  approach  to  meet  DoD’s  continuing  need  to  support  systems  over 


increasingly  long  life  cycles  in  an  environment  of  decreasing  resources.  In  a  time  when  the 
development  of  a  complex  system  can  span  several  generations  of  the  faster  moving  technologies, 
open  system  architectures  offer  the  tantalizing  prospect  of  facilitating  performance  upgrades  at 
affordable  costs  for  the  life  cycle  of  the  system.  The  potential  and  practice  of  open  systems 
design  as  an  emerging  topic  within  the  systems  engineering  discipline  has  now  been  with  us  for 
several  years.  In  addition,  the  use  of  open  systems  has  received  the  attention  and  support  of  the 
highest  levels  of  DoD.  In  1996,  DoD  issued  a  revised  directive  DoD  5000. 2-R  that  instructs 
program  managers  to  employ  open  systems  as  a  design  consideration  in  defense  systems 
engineering  [2] .  The  systems  engineering  process,  with  specific  reference  to  the  consideration  of 
open  systems  designs,  is  integral  to  achieving  the  benefits  of  open  systems  designs. 

While  there  are  many  definitions  of  open  systems  [3] ,  most  have  a  few  characteristics  in 
common.  Open  systems  are  those  that  can  be  supported  by  the  marketplace,  rather  than  being 
supported  by  a  single  (or  limited)  set  of  suppliers,  due  to  the  unique  aspects  of  the  design 
chosen.  Open  systems  architectures  are  achieved  by  having  the  design  focus  on  commonly  used 
and  widely  supported  interface  standards.  One  might  think  in  terms  of  the  axle-wheel-tire 
interfaces  employed  on  commercial  cars.  By  adhering  to  common  standards  at  the  interfaces,  the 
consumer  is  able  to  buy  tires  from  a  multitude  of  suppliers,  rather  than  being  forced  to  buy  from 
a  single  source,  as  might  be  the  case  if  the  interface  characteristics  were  unique  to  a  single 
supplier.  This  ensures  costs  and  quality  that  are  controlled  by  the  forces  of  competition  in  the 
marketplace.  Furthermore,  the  continued  support  of  the  system  is  not  subject  to  the  risks 
associated  with  having  a  single  supplier  go  out  of  business  or  cease  supporting  the  standard.  As 
the  technologies  associated  with  tires  change  with  time,  the  customer  can  continue  to  upgrade  and 
support  his  vehicle  with  tires  that  are  built  to  the  accepted  industry  standard  (e.g.,  conventional 
sidewall  bias-ply  technology  tires  to  steel-belted  radial-ply  technology  tires) . 

However,  despite  all  the  high-level  attention  on  open  systems,  DoD  program  managers 
must  exercise  some  care  and  judgment  in  their  application  of  the  open  systems  approach.  It  does 
not  represent  a  new  approach  that  replaces  and  makes  obsolete  previous  approaches  to 
engineering  complex  systems.  Moreover,  managers  should  not  simply  implement  an  open 
standard  without  careful  consideration  of  where  (in  the  system  hierarchy)  it  makes  sense  to 
impose  standards  nor  should  they  simply  grasp  for  a  commercial  item  (Cl)  solution,  whether  or 
not  the  solution  leads  to  the  benefits  of  open  systems  architectures.  Such  actions  may  encourage 
program  managers  to  declare  that  they  are  achieving  open  systems  attributes,  whether  or  not  the 
system  design  is  well  thought  out  to  take  full  advantage  of  the  benefits  that  the  open  systems 
approach  offers.  This  may  give  the  appearance  of  achieving  open  systems  architectures  but,  in 
fact,  such  short-sighted  decisions  work  against  the  long  term  viability  of  the  system.  The  open 
system  concept  does  not  replace  the  need  for  following  a  rigorous  systems  engineering  process 
but,  in  fact,  requires  more  rigor  to  ensure  that  open  systems  benefits  are  achieved. 

4.  Open  Systems  Applied  Within  the  Systems  Engineering  Process 

Systems  engineering  is  fundamentally  a  problem  solving  process  that  translates  needs  and 
requirements  as  inputs  into  designs  and  products  as  outputs.  The  systems  engineering  process 
typically  starts  with  problem  definition  as  requirements  are  analyzed.  Alternative  solutions  or 
system  architectures  are  developed,  usually  initially  through  techniques  such  as  functional 
analysis  and  data  flow  analysis.  Alternative  physical  designs  are  then  developed  to  satisfy  the 


functional  or  data  flows.  Trade  studies  and  risk  analyses  are  applied  to  select  a  preferred  design 
solution,  and  that  solution  is  verified  against  the  original  requirements. 

This  process,  properly  applied,  results  in  a  flow  down  of  requirements  from  the  system 
level  to  the  items  below  system  level.  As  these  requirements  are  flowed  down,  the  design 
requirements  for  the  items  below  system  level  are  defined.  Once  these  lower  level  design 
requirements  are  finalized,  the  design  process  proceeds  to  completion.  The  result  is  a  design 
which  associates  physical  entities  with  the  functions  that  the  system  must  perform,  and  is 
consistent  with  the  levels  of  performance  required  and  with  the  interfaces  specified. 

This  process,  applied  without  constraints,  will  lead  to  the  design  of  a  system  in  which 
every  item  is  optimized  to  the  requirements  in  terms  of  function,  performance,  and  interface. 
Too  often,  the  results  in  DoD  have  been  systems  that  are  unique  in  their  designs,  which  perform 
their  missions  quite  well,  but  which  require  unique  equipment  and  parts  to  support  them,  and 
which  can  be  supported  only  by  a  limited  set  of  suppliers.  This  has  historically  been  a 
prescription  for  “closed”  systems  that  are  both  difficult  and  costly  to  support. 

The  challenge  in  DoD  is  to  design  systems  to  take  advantage  of  open  systems  concepts 
where  that  makes  sense,  while  continuing  to  meet  the  needs  and  requirements  of  operational 
forces.  The  solution  is  not  to  suddenly  abandon  good  systems  engineering  and  simply  impose 
standard  interfaces  at  some  point  in  the  system,  nor  is  the  answer  likely  to  be  found  in 
indiscriminately  importing  Cl  solutions  into  the  system  architecture.  Rather,  the  real  answer  is 
to  be  found  in  performing  good  systems  engineering  while,  as  DoD  dictates,  employing  open 
systems  as  a  design  consideration  from  the  outset.  The  challenge,  then,  is  to  integrate  systems 
engineering  and  open  systems  design. 

To  this  end,  the  use  of  architectures  in  DoD  has  become  a  preferred  management 
approach  for  implementing  an  open  systems  approach  [4] .  DoD  has  implemented  this  concept 
by  defining  an  interrelated  set  of  architectures:  Operational,  System,  and  Technical  (illustrated  in 
Figure  2).  Basically,  the  Operational  Architecture  specifies  the  “user  requirements”  which  are 
used  as  inputs  to  the  systems  engineering  process  to  eventually  build  the  weapon  system.  The 
Technical  Architecture  and  Product  Lines  constrain  the  system’s  design  during  the  system 
engineering  process.  The  System  Architecture  emerges  as  an  output  and  is  constructed  to  satisfy 
Operational  Architecture  requirements  within  the  rules  and  standards  defined  in  the  Technical 
Architecture.  Technical  architectures  are  particularly  important  to  the  systems  engineering 
process  because  they  provide  the  building  codes  for  implementing  systems  upon  which 
engineering  specifications  are  based,  common  building  blocks  are  built,  and  product  lines  are 
developed.  Note  that  while,  each  of  these  architectures  by  themselves  build  nothing,  together 
they  provide  a  management  tool  which  facilitates  evolutionary  acquisition  by  supporting 
insertion  of  new  technology,  component  reuse,  improved  weapon  systems  interoperability  and 
the  accommodation  of  evolving  user  requirements. 


The  Building  Codes 


The  Blue  Print 


Figure  2.  Architectures  and  the  Systems  Engineering  Process 


Who  chooses  the  technical  architecture?  Does  the  government  choose  the  architecture; 
does  industry  choose  the  architecture  or  is  the  architecture  chosen  in  concert?  The  government 
may  specify  key  performance  attributes  of  system  building  blocks  including  internal  interface 
standards.  However,  doing  so  without  adequate  input  from  industry  stifles  innovation,  limits 
performance  and  increases  cost  by  attempting  to  substitute  our  wisdom  for  that  of  the  designer. 
If,  on  the  other  hand,  we  provide  no  guidance,  we  may  encourage  development  of  proprietary 
architectures,  interfaces  and  components.  That  would  leave  DoD  in  a  position  where  it  must 
maintain  and  modify  a  unique  product  with  a  single  supplier  at  a  high,  non-competitive  price. 
Each  program  must  chose  a  path  between  these  two  extremes.  A  desirable  situation  is  for  there 
to  be  a  consensus  among  potential  prime  contractors  and  their  key  suppliers  on  application  of 
widely  accepted  standards. 

Using  an  open  systems  approach  to  the  systems  engineering  process  helps  achieve  an 
integrated  design  solution  which  is  resilient  to  changes  in  technology  throughout  the  life  of  the 
system.  Open  systems  (engineering)  achieves  this  resiliency  in  “life-cycle  supportability”  by 
engineering  systems  according  to  the  following  principles  and  practices  (illustrated  in  Figure  3) : 
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Figure  3.  Open  Systems  Analysis  for  Integrated  Design  Solution 


•  Identify  as  critical  the  interfaces  to  subsystems  or  components  which  are  likely  to 
change  due  to  their  dependence  on  rapidly  evolving  technology,  are  likely  to  have 
increasing  requirements,  have  high  replacement  frequency  or  have  high  costs.  Such 
components  present  both  the  highest  obsolescence  risks  and  the  greatest  opportunity 
for  future  technology  insertion. 

•  Use  open  standards  for  these  critical  interfaces  that  are  supported  by  the  broader 
community,  ,  are  considerate  of  life-cycle  support  requirements,  permit  evolution 
with  advances  in  technology,  and  support  technology  insertion. 

•  Use  a  modular  design  approach  combined  with  well  defined  standards-based  interfaces 
among  modules  to  isolate  the  effects  of  change  in  evolving  systems,  serving  to  reduce 
the  need  for  redesign  as  the  system  is  upgraded. 

•  Identify  the  lowest  level  at  which  the  government  maintains  control  over  the  interface 
standard,  and  anticipate  how  this  level  may  change  over  time.  Below  this  level  the 
contractor  is  permitted  to  use  its  best,  perhaps  proprietary,  practices  to  improve  or 
discriminate  its  product  in  the  marketplace. 

•  Verify  all  performance  requirements  and  reevaluate  their  stringency.  Reallocate 
requirements  as  necessary  to  permit  the  wider  use  of  open  standards  throughout  the 
system. 

•  Implement  consistent  conformance  management  practices  to  ensure  that  products 
procured  for  the  system  conform  to  the  established  profile  so  as  to  prevent  being 
limited  to  one  supplier  who  might  unilaterally  extend  that  interface. 


The  key  to  achieving  the  benefits  of  open  systems  designs  lies  in  making  open  systems  an 
integral  part  of  the  classic  systems  engineering  process  and  in  applying  open  systems  at  all  stages 
of  the  product  life  cycle.  The  open  systems  approach  to  design  will  never  replace  or  make 
obsolete  that  process  —  if  anything,  it  demands  that  the  process  be  even  more  rigorously  applied. 
As  is  illustrated  in  Figure  4,  each  of  the  major  aspects  of  the  systems  engineering  process  must 
include  consideration  of  open  systems  design  concepts  and  principles: 
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Figure  4.  Integrating  Open  Systems  and  the  Systems  Engineering  Process 


Requirements  analysis  must  emphasize  the  balancing  of  business  goals  (costs,  common 
use,  life  cycle  supportability,  etc.)  with  technical  goals  (functionality,  performance,  interfaces, 
and  other  constraints) .  As  the  systems  engineering  process  iterates,  the  requirements  analysis 
step  is  revisited  to  consider  cost-performance  tradeoffs  to  meet  most  performance  objectives 
while  achieving  as  large  as  possible  reductions  in  life-cycle  costs.  The  stringency  of  requirements 
is  reevaluated  to  consider  the  use  of  open  standards  for  interfaces  as  performance  requirements 
are  balanced  (weighed)  against  business  requirements.  To  do  this,  engineers  need  to  be  better 
trained  to  incorporate  life  cycle  cost  in  design  and  provided  tools  which  allow  them  to  rapidly 
assess  life  cycle  cost  impacts.  Under  any  circumstances,  users  have  a  requirement  for  systems 
that  are  supportable  and  affordable,  and  these  requirements  demand  that  one  consider  open 
architectures  as  system  elements  are  defined. 

Functional  analysis  and  allocation  must  define  an  architecture  which  provides  a 
framework  for  identifying  interfaces  critical  to  achieving  system  business  and  technical 
performance  goals.  Requirements  should  be  allocated  with  a  view  toward  achieving  functional 
modularity.  Functional  modularity  can  facilitate  physical  modularity  and  the  use  of  open 
interfaces  to  support  system  evolution  goals.  As  the  systems  engineering  process  iterates,  this 
step  is  revisited  to  allocate  functionality  so  as  to  modularize  those  components  or  subsystems 
which  are  dependent  on  rapidly  evolving  technology,  have  high  replacement  frequency  or  are  high 
costs  and  to  reallocate  performance  or  business  requirements  as  necessary  to  allow  for  the  use  of 
open  interface  standards  during  synthesis. 

Synthesis  and  design  should  continue  the  search  for  alternative  system  architectures 
that  will  satisfy  requirements.  To  be  effective,  good  design  synthesis  demands  an  iterative 
approach  that  involves  revisiting  the  functional  allocations  and  developing  alternative  physical 


solutions  until  a  balanced  design  (in  terms  of  cost,  performance,  and  risk)  is  achieved. 
Modularity  should  be  used  in  system  design  where  interfaces  between  modules  are  based  on 
open,  widely-supported  interface  standards.  Modularity  should  be  based  on  well-defined 
interfaces  to  isolate  components  that  are  likely  to  change  over  time  (e.g.,  dependent  on  rapidly 
evolving  technology,  have  high  replacement  frequency)  or  are  high  costs  since  these  components 
present  the  highest  obsolescence  risks  and  the  greatest  opportunity  for  future  technology 
insertion.  Well-defined  interfaces  are  used  to  decouple  system  components  and  define  firewalls  to 
contain  evolution  of  lower  level  component  upgrades  and  modifications,  thereby  minimizing 
future  redesign,  and  possibly  retesting,  when  components  are  upgraded.  In  addition,  physical 
modularity  should  be  aligned  with  functional  partitioning  to  facilitate  the  replacement  of  specific 
subsystems  and  components  without  impacting  others. 

Design  iteration  should  sequentially  reconsider  the  allocations  of  function  and 
performance  that  define  the  design  requirements  for  each  system  component  with  the  objective  of 
achieving  user  (customer)  requirements  within  an  optimal  open  systems  solution.  From  an  open 
systems  perspective,  if  this  sequential  iteration  is  stopped  as  soon  as  the  first  acceptable 
technical  solution  is  achieved,  there  are  two  probable  results:  either  the  solution  will  be  shown  to 
(1)  require  unique  designs  that  require  new  development,  or  (2)  an  open  solution,  if  imposed  at 
this  point,  will  likely  not  meet  all  the  requirements  of  the  user.  However,  in  most  cases,  a  final 
design  can  almost  certainly  be  developed  that  results  in  system  architectures  that  include  some 
items  that  are  “open”  and  other  elements  that  are  not.  Although  open  designs  are  the  objective,  it 
is  neither  necessary  nor  in  some  cases  even  possible  that  every  element  or  item  of  most  complex 
systems  be  totally  open. 

Systems  analysis  and  control  must  include  conformance  management  incorporating 
both  implementation  and  applications  conformance  testing.  The  selected  conformance  approach 
must  be  fully  defined  and  documented  so  that  it  is  understood  by  all  parties.  The  degree  to 
which  open  systems  benefits  can  be  achieved  will  depend  largely  on  how  well  the  product  design 
conforms  to  selected  standards.  Completely  defined  interface  profiles  will  allow  vendors  to  build 
standards-based  components  and  allow  users  to  design  systems  to  use  standards-based 
components.  In  all  cases,  candidate  components  should  be  tested  against  detailed  system  profiles 
to  ensure  that  components  conform  to  profiles. 


5.  Open  System  Design  Challenges 


The  open  approach  to  system  design  offers  considerable  benefits,  already  discussed,  in 
terms  of  life  cycle  support,  affordability  and  timely  technology  insertion.  The  approach  also 
carries  with  it  some  substantial  differences  in  the  way  that  systems  will  be  managed  and 
supported.  Since  by  its  nature  open  systems  designs  will  involve  increased  use  of  commercial 
and  non-developmental  items  in  systems  architectures,  the  government  will  necessarily  have  to 
plan  for  significant  differences  in  the  way  systems  are  managed  from  a  technical  perspective. 
These  differences  cut  across  almost  every  aspect  of  engineering  management,  and  while  space 
prohibits  an  exhaustive  treatment,  examples  include  the  following: 


•  Standards  based  architectures  lessen  the  degree  of  control  that  DoD  can  expect  to 
exert.  Changes,  fixes,  and  updates  will  likely  be  under  the  vendor’s  control.  This  can 
have  a  significant  impact  on  system  support. 

•  Standards  based  elements  of  the  architecture  are  likely  to  be  faster  and  cheaper  to 
acquire  than  a  comparable  developmental  item  but  may  take  more  time  to  integrate 
and  test. 

•  Standards  selection  is  risky.  Acquisition  will  require  substantially  more  knowledge  of 
the  current  state  of  the  art  and  the  marketplace  on  the  part  of  the  government. 

•  Standards  evolve  with  time.  It  is  difficult  to  project  the  extent  to  which  a  given 
standard  will  endure.  It’s  equally  challenging  to  determine  when  to  move  from  one 
standard  to  the  next. 

•  Standards  based  architectures  tend  to  change  the  focus  of  systems  engineering  from 
design  to  integration.  The  challenge  is  to  achieve  performance  requirements  without 
detailed  control  over  the  component  design  specification. 

•  An  item,  once  integrated,  may  affect  other  system  parameters.  Commercial  and  NDI 
items  make  testing  an  on-going  and  continuing  activity  to  verify  that  items  can 
integrate  successfully  into  systems. 

•  The  use  of  commercial  and  NDI  requires  that  support  concepts  be  developed  early  in 
the  acquisition  cycle. 


While  this  is  hardly  an  exhaustive  list,  it  makes  the  point  that  open  systems  engineering 
introduces  new  issues  into  the  management  of  the  technical  aspects  of  programs.  There  are  many 
potential  benefits,  but,  likewise,  there  are  challenges  and  problems  that  the  manager  must  be  alert 
to  anticipate  and  overcome. 

6.  Summary 


The  objective  of  open  systems  acquisitions  is  to  provide  the  warfighter  the  most  effective 
weapon  systems  possible.  An  open  systems  approach  to  systems  engineering  facilitates  this 
throughout  the  life  of  the  system.  Open  systems  designs  provide  an  opportunity  to  achieve 
affordable  designs  which  can  more  readily  accommodate  changing  technology  while  promoting 
multiple  sources  of  supply;  however,  to  achieve  good  open  systems  designs  first  demands  that  a 
disciplined  systems  engineering  approach  be  taken  to  defining  the  appropriate  elements  in  the 
system  to  be  opened. 

Most  systems  will  not  be  completely  open  in  their  architectures,  but  a  well-engineered 
design  will  result  in  a  design  strategy  that  takes  maximum  advantage  of  the  benefits  available  from 
opening  the  design.  Associated  with  an  open  approach  is  the  need  to  focus  on  and  manage  the 
interfaces  between  open  system  elements  and  other  elements  of  the  system.  Choosing  well- 
known  and  accepted  industry  standards  and  applying  them  in  a  controlled  manner  will  go  far 
toward  achieving  the  desired  results.  Overall,  the  system  architecture  resulting  from  a  system 


engineering  process  should  be  linked  to  a  business  case  analysis.  Architecture  decisions  should  be 
traceable  to  performance,  life-cycle  cost,  schedule,  and  risk.  The  alternatives  for  support, 
maintenance  and  upgrade  should  be  evaluated. 

For  maximum  benefit,  an  open  systems  approach  should  focus  on  planned  use  of  designs 
across  a  system  or  domain.  As  designs  are  opened,  managers  must  be  aware  of  the  fact  that 
support  and  acquisition  strategies  will  necessarily  be  impacted.  These  impacts  must  be 
anticipated  and  planned  for  from  the  outset  during  system  design. 


More  open  systems  information  and  reference  materials  are  available  on  the  Open  Systems 
Joint  Task  Force  home  page  on  the  Worldwide  Web  at  http://www.acq.osd.mil/osjtf _ 
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